Call requests in wireless communication systems are generally known, including private call requests and talkgroup call requests. A private call request results when a user of a given communication unit (e.g., a hand-held portable or in-car mobile radio) wishes to communicate with another user on another communication unit. The call is "private" in the sense that no other users are allowed to participate in the requested communication. Talkgroup call requests result when a member of a talkgroup (a logical grouping of individual communication units) wishes to communicate with the other members of that talkgroup. If granted, the talkgroup call request allows all members of the talkgroup to participate in and monitor the communication. Also, a multigroup call request occurs when a member of a multigroup (a logical grouping of multiple talkgroups) attempts to communicate with the other members of the multigroup, including members of talkgroups which may currently be engaged in a talkgroup call. The resulting multigroup call allows all members of the multigroup and the targeted talkgroup to participate in and monitor the multigroup call. When a call request is granted, the resulting call is termed an "active call".
However, there are instances (for example, in wide-area multi-site communication systems such as SMARTZONE systems by Motorola, Inc.) in which call requests may not be immediately granted. Such call requests are termed "busied calls" and placed into a "busy queue". Typically, busied calls result from one of two conditions. In the first condition, a busied call will result if there are insufficient resources (e.g., wireless communication channels, or infrastructure-based resources) available to complete the requested service at the time of the call request, referred to as a resource busy. Until sufficient resources become available, the busied call remains in the busy queue. In the second condition, a busy call results because a contention condition exists between a party targeted in the call request and an active call or a previously busied call, referred to as a contention busy. That is, the called (targeted) party in the call request is currently engaged in an active or busied call and is therefore unable to participate in the requested call. As described below, prior art methods of converting busied calls to active calls (often referred to as a "busy conversion") address the first condition, but not the second.
FIG. 1 illustrates the prior art method for busy conversions. When an active call terminates at step 102, a check is made of the busy queue at step 104 to see if there are currently any busied calls. If so, the next busied call in the queue (according, first, to service or unit priority and, second, to duration within the queue) is accessed at step 106 and, at step 108, it is determined whether the busied call, in order to be converted to an active call, requires any of the resources previously used by the now-terminated active call. If so, the busied call is converted, if possible and in accordance with well-known techniques, to an active call at step 110. The process of attempting to convert busied calls continues until it is determined that there are no more busied calls in the busy queue (step 104) or until it is determined that the resources made available by the terminated call have been consumed in the process of converting busied calls (step 112). An example of this process, and its inherent shortcomings, is illustrated in FIG. 2.
FIG. 2 illustrates the progression of various active and busied calls in accordance with the method of FIG. 1. In FIG. 2, the progression of time is illustrated from top to bottom and, in the example shown, it is assumed that the system comprises three sites; Site 1 has one communication resource available; Sites 2 and 3 have three communication resources available, respectively. Initially 201, one of three communication units (SU 1, SU 2, SU 3) is registered at each site, as shown. Additionally, there is a talkgroup (TG A) with members registered at Sites 1 and 2, which members are not communication units SU 1 and SU 2. Subsequently 202, the first communication unit (SU 1) calls the second communication unit (SU 2) resulting in the active call (SU 1-SU 2) shown in the active calls column; the sole resource available at Site 1 is used by this active call.
When a talkgroup call request is made 203 requiring resources in Sites 1 and 2, it is busied and placed in the busy queue (shown as TG A in the busy queue column) because there are insufficient resources available at Site 1. Also, when a private call request is made 204 by the third communication unit (SU 3) targeting the second communication unit (SU 2), it is denied not because of insufficient resources (Sites 2 and 3 have sufficient resources available), but because the second communication unit is currently involved in an active call thereby creating a contention busy. Thus the private call request is placed in the busy queue, shown as SU 3-SU 2 in the busy queue column. When the active call later terminates 205, it is removed from the active call column, and the busy queue is checked to see if any busied calls can be completed using the recently-released resources. Thus, it is determined that the busied call corresponding to the talkgroup call request can proceed because the necessary resources are now available at Site 1; it is removed from the busy queue and placed 206 in the active call column.
At this point, it is evident that the other busied call in the busy queue (SU 3-SU 2) should be able to proceed because the contention condition no longer exists and there are sufficient resources available to complete the call. However, because all of the recently-released resources have been consumed (or, in practice, because the busied call does not require any of the recently-released resources), the busied call will not be converted 207 to an active call. In effect, the prior art method is not capable of differentiating between a resource busy and a contention busy and, as a result, will cause busied calls that might other wise be converted to remain in the busy queue. The delays due to this failure to convert busied calls results in user dissatisfaction with system performance. Thus, a need exists for a method of converting busied calls that is capable of handling contention busied calls.